F5 EAPでシグネチャを例外登録したときの動作と修正方法を調べてみた

F5のSaaS型WAFであるEssential App Protectのシグネチャ例外登録の方法と動作、その修正方法をまとめました。修正について特に気をつける必要があります。

#AWS

#セキュリティ

#WAF

#F5 Essential App Protect

#F5

臼田佳祐

2020.07.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、WAF活用していますか？

今回はF5のSaaS型WAFであるEssential App Protect(EAP)でシグネチャを例外登録した際の動作とその修正方法を調べてみました。

F5 EAP自体について詳しく知りたい場合はまず下記をご覧ください。

F5 EAPのシグネチャ

EAPでは大きく3種類のアプリケーション保護機能があります。

ハイリスク攻撃の軽減(High Risk Attack Mitigation)
悪意のあるIPからの保護(Malicious IP Enforcement)
脅威キャンペーン(Threat Campaigns)

そのうちEAP上でユーザーが調整するシグネチャはHigh Risk Attack Mitigationに含まれるの攻撃シグネチャになります。2020/07/27現在ではシグネチャが4,851個存在していて、F5によりメンテナンスされています。

シグネチャの例外登録とその動作

シグネチャの例外登録の方法とその動作について説明します。

まず何かのアクセスがBlockまたはMonitoringで検知された場合にはSecurity Incidentsというイベントが発生します。このイベントを「VIEW EVENTS」から確認します。該当のイベントを選択した際に右側から詳細が出てきますが、この右下に「Mark as exception」というボタンがありここから例外登録が可能です。

「Mark as exception」を押すと確認画面が出ます。イベントに対応する複数のシグネチャの例外登録が一度に登録されると表示されるので登録します。

これで反映が完了です。変更された内容は「VIEW EVENTS」の「Service-specific」の設定変更の中に含まれていて、Descriptionが「Mark as exception」として登録されます。変更内容は残念ながら現状では部分的でなく、WAF全体のConfigurationが表示されます。

Configurationにおける例外のスキーマは公式ドキュメントに詳細の説明があります。下記のような構造になっています。

 "high_risk_attack_mitigation": {
     "enabled": true,
     "enforcement_mode": "blocking",
     "signature_enforcement": {...},
     "allowed_methods": {...},
     "disallowed_file_types": {...},
     "api_compliance_enforcement": {...},
     "http_compliance_enforcement": {...},
     "websocket_compliance_enforcement": {...},
     "geolocation_enforcement": {...},
     "ip_enforcement": {...},
     "exceptions": {
         "url_objects": {...},
         "parameters_objects": {...},
         "headers": [...],
         "cookies": [...],
         "evasions": [...],
         "http_compliance": [...],
         "attack_signatures": [...]
     }
 }

いくつか要点を解説します。

例外登録はURL・パラメータ・ヘッダ・Cookieなどの条件と合わせて対応するシグネチャを除外する場合と、シグネチャのみで除外する場合があります。

「Mark as exception」から登録すると、シグネチャが該当するURLやパラメータなどを条件に含めて登録されます。

例えば上記画像で紹介したものはRefererに含まれている文字でのSQLインジェクションを検知したイベントで、シグネチャとしてはヘッダに含まれる文字列に対してSQLインジェクションを検知するものであったため、例外登録すると下記の条件で例外登録されました。

ヘッダ名がReferer(Config上ではBase64して登録されるためUmVmZXJlcg==)
シグネチャIDが200002424または200002171または200002836

上記はANDとなります。

他にもパラメータに対するSQLインジェクションを検知するシグネチャを例外登録すると下記のようになります。

パラメータ名がid(Config上ではaWQ=)
シグネチャIDが...

つまりシグネチャ自体がヘッダやパラメータ用で用意されているため、例外登録したら該当したヘッダやパラメータを条件として例外登録されます。

そのため「Mark as exception」から例外登録したら自動的にすべてのリクエストからそのシグネチャが例外とされるわけではありません。そこは安心ですね。

注意点としては条件が細かくないため例外登録により必要以上に影響がある可能性があります。

具体的には上記例のようにパラメータで除外された場合に別のページの同名パラメータも除外対象となり、そちらに適切な保護が適用されない可能性があります。上記例はidパラメータを例外条件としているため、別のページのidパラメータも除外対象となります。残念ながら現状これに複合的な条件を加えて例外対象をさらに絞り込むことはできないようです。